A while ago a non-tech colleague mentioned the term "washes it's face" when describing a business case. They meant that the business case would break even. I liked the term, and found that it was a good way of helping teams make decisions - especially around technical debt.
At one point I was helping a number of teams migrate their applications to the cloud. The majority were relatively straightforward .Net on-premise web applications, as we had identified Azure Web App as a great fit. In most cases the coding changes were fairly trivial, but the teams found building robust deployment pipeline more challenging. The applications often integrated with a number of different api's and teams often asked for advice when evaluating potential refactoring or recoding.
The conversation usually went like this:
"We can move our application to the cloud in 3 months. We already know that it will bring significant performance and scalability benefits, as well as productivity benefits resulting from our supercharged cloud SDLC... but there's this one horrible bit of code. We've put off fixing it for years. Shouldn't we fix it before migrating?".
The teams asking the question were well intentioned. They cared about their application and it felt "wrong" to move some of their old, inefficient code to the shiny new platform, but I found the "washing it's face" analogy to be effective in helping them choose a path.
My answer was along these lines:
"If you don't fix the code, 99% of your application will run faster, but your old code will be slightly more problematic. You are already committed to a full re-test of the application as part of the migration. So if you can re-write the old code without affecting the project timelines, then you can take advantage of the full re-test. If you can't achieve it within the project timelines, then leave it, and you'll be able to go back and fix it later with the benefit of the new and improved SDLC."
The team saw a problem with 2 negative options:
- Put bad code in the cloud, or
- Delay the project
I helped them reframe it to a choice between two positive options:
- The refactor would normally require a full re-test, so we can reduce the overall time for re-writing by taking advantage of the migration, or
- We can claim a load of benefits immediately, and fix the problem later with the benefits of a faster, safer SDLC. Either way, resolving this technical debt will be quicker than we previously thought (which was why it was technical debt in the first place).
Summary
Technical debt can be a difficult topic to deal with, and this is just one possible technique. I frequently find that development teams struggle to genuinely own their tech debt, which can be frustrating. "You made the mess , so...". Sometimes its simply a case of providing encouragement. If a team is motivated by a desire to ship features, then they can be motivated to remove the impediments slowing their progress. If a team isn't motivated to ship features....then management has a different problem to deal with!